Configuring your computer to page you

By Al Alexander

Alvin J. Alexander is an independent consultant specializing in UNIX and the Internet. He has worked on UNIX networks to support the Space Shuttle, international clients, and various Internet service providers. He has provided UNIX and Internet training to over 400 clients in the last three years.

Imagine that you’re at home one night, getting ready to go on a two-week vacation to a terrific beach. As you’re packing your swimsuit and suntan lotion, your pager suddenly starts beeping. "Oh no," you think, "there goes my vacation."

You look at the pager, fearing the worst. "Who’s calling me, and what do they want?" Then you see the number and realize "Aha! My computer just paged me, and it’s telling me that the root partition is nearly full." To solve the problem, you quickly dial up your computer and move a directory from the root file system to one that has some extra space. You also send yourself some E-mail to remind yourself to reorganize some files when you return from your vacation.

You then continue packing and head to the sun, sand, and water. Your vacation was rescued because your computer had the intelligence to recognize the potential problem and to call you before a larger disaster occurred. In this article, we’re going to show you how to turn this fantasy into a reality. All you need is a way to make your computer system(s) page you when it detects an impending disaster.

How did this happen?

A few years ago, I created a UNIX daemon named monitor. Its purpose is to monitor my computer systems and alert me if something bad is happening or is about to happen. If so, the computer should try to contact me. Early versions of monitor sent E-mail, displayed messages on the console, and sent printouts to a printer near my cubicle to alert me of potential problems.

Lately, as my computer system responsibilities have spread throughout multiple states (and countries), I extended monitor to fax me and to send messages to my pager.

This proactive approach to system management is much better than a reactionary, defensive approach. Rather than spending hours fixing problems that have already occurred, you can spend minutes to avert them.

This solution is actually very simple to implement. First, you need a process that monitors your system for impending doom, and you need a way for your computer to send you a page. For the basics on a system-monitoring daemon, see the article "Writing a Script to Monitor Your System".

Solving the paging problem

In order to use this method of making your computer page you, three things are necessary:

1. A digital pager
2. A Hayes-compatible modem connected to your computer
3. The UUCP programs installed

The system is very simple. The monitor program, not listed here, must detect system problems. When a problem occurs, the monitor program uses a UUCP program to call your pager and leave you a message. In order to keep things simple, we encode the message into a seven-digit number. The top four digits identify the system that has the problem, and the lower three digits specify the problem.

Sending a page

Once you’ve set up your system properly, you can initiate the page in several ways. The simplest is to use the cu command, like this:

$ cu SystemName
Connect failed: CALLER SCRIPT FAILED

Please note the error message that cu prints after the page is done. (The error message doesn’t occur for about a minute after you enter the command.) You can safely ignore this error because it’s a by-product of the way this method works.

A more complex way to issue the page is to use the Uutry command. Because the Uutry program isn’t likely to be in your path, you need to specify its full pathname, like this:

$ /usr/lib/uucp/Uutry -r SystemName
/usr/lib/uucp/uucico -r1
-s SystemName -f -x5 >/tmp/pgr0001 2>&1&
tmp=/tmp/pgr0001
name (SystemName) not found; return 
FAIL
name (DEFAULT) not found; return
FAIL
name (OTHER) not found; return FAIL
attempting to open /var/uucp/.Admin/
account
Job grade to process -
conn(pgr0001)
Trying entry from '/etc/uucp/Systems' 
- device type ACU.
...

Here, I’ve trimmed away much of the output. Please note that when you use Uutry to page your system, the Uutry command will wait for you to stop the program. Thus, it’s not useful for automated paging.

This method of sending the page is interesting because you can see the dialog between Solaris and your modem. The Uutry program also shows you the best way to send a page: with the uucico program.

Here’s why I believe the uucico program is the best method to use:

1. You can override any retry time limits with the -r option.
2. It doesn’t emit an error message when it sends the page.
3. You can tell it not to fill the screen with diagnostic information.

Like Uutry, the uucico program probably isn’t in your path. So to execute the uucico program, you should invoke it like this:

$ /usr/lib/uucp/uucico -r1
-sSystemName

Once you set up your system correctly, you’ll be able to send pages easily. Now let’s take a look at how to set up the system.

Setting up UUCP

In the previous examples, I used SystemName without any explanation. It turns out that this System-Name is the heart of the paging system. You simply create a set of fake systems in the /etc/uucp/Systems file of each computer that can send a page. Each SystemName entry corresponds to a particular piece of problem code the system can send to you. Figure A shows some of the entries I placed in my /etc/uucp/Systems file.

Figure A: This portion of an /etc/uucp/Systems file assigns the phone number of your pager and the pager code to a fake system name.

pgr0001 Any ACU Any 5551212,,,,,0001001#
pgr0002 Any ACU Any 5551212,,,,,0001002#
pgr0003 Any ACU Any 5551212,,,,,0001003#
pgr0004 Any ACU Any 5551212,,,,,0001004#
pgr0005 Any ACU Any 5551212,,,,,0001005#
pgr0006 Any ACU Any 5551212,,,,,0001006#
pgr0007 Any ACU Any 5551212,,,,,0001007#
pgr0008 Any ACU Any 5551212,,,,,0001008#
pgr0009 Any ACU Any 5551212,,,,,0001009#
pgr0010 Any ACU Any 5551212,,,,,0001010#

If you want a more detailed explanation of how to set up the /etc/uucp/Systems file, you may want to read the article "Configuring the Devices and Systems Files for cu" in the May issue, as well as peruse the man pages for the UUCP programs.

For the purposes of this article, all you need to do is create lines starting with your fake system name, followed by "Any ACU Any", followed by the phone number to dial. We suggest you use pgrWXYZ as the system name, where pgr is the fake pager system, and WXYZ is the problem code that the system is reporting.

The pager phone number

As you can see in Figure A, we’re manipulating the phone number to do all the work. For the purposes of this article, let’s assume that your digital pager number is 555-1212. The phone number for pgr0001 is 5551212,,,,,0001001#.

The first part of the number is straight-forward - it simply dials 555-1212. For a Hayes-compatible phone, a comma tells the modem to pause for two seconds. Thus, the five commas tell the modem to pause for 10 seconds. Next, the modem emits the code 0001001. Finally, the modem emits a pound sign (#), just as if you’d typed it on your telephone keypad.

The code simply encodes the system number as four digits and the problem code as three digits. So this code tells us that computer system 1 had problem code 1. One problem this paging system has is that it doesn’t automatically hang up quickly. Luckily, the system connected at 555-1212 interprets the pound sign as a command to hang up.

You may have to tune the telephone number to work with your digital pager and phone system. For example, some systems require that you dial 9 to get an outside line. For this, you’ll want to insert a 9, at the beginning of the phone number. Similarly, if you have call waiting, you’ll want to insert the code that turns off call waiting for the next call. In my area, it’s *70, so I’d add *70, at the start of the phone number. In both these cases, we add a comma after the prefix to allow the command to be processed before we emit the rest of the digits in the phone number. Some equipment needs this delay, or digits may be missed. For example, if we need to do both, we may define a system as

pgr0003 Any ACU Any 9,*70,5551212,,,,,0001003#

I used a 10-second delay because my pager system normally picks up on the second ring, then gives a short voice prompt. If you have a longer voice prompt, you may want to increase the timeout period.

Lacking elegance?

Two parts of this system aren’t elegant. The first involves calling my pager number, waiting 10 seconds, then blindly sending the numeric code that indicates the system name and error code. In a more perfect world, I would wait for a voice response from the pager system I’m calling, then send the numeric code. However, using a simple UUCP dialing system, this isn’t possible. Does that mean this solution isn’t elegant?

I’ve tested my pager system very heavily and determined that, 99 times out of 100, the pager system is ready to receive numeric input in five seconds after I dial the last digit of the pager phone number. At 25 seconds after the last number has been dialed, if my pager hasn’t received a numeric code, it hangs up. Given that window between five and 25 seconds, I’ve elected to wait 10 seconds before transmitting the computer/error code. It may not seem elegant, but it hasn’t failed yet.

The second ugly part of the system is that I can’t hang up the phone properly. After the computer makes the call and transmits the computer/error code sequence, the # signal tells the pager system to hang up on my calling computer, which it does. That works fine, but my calling computer never hangs up the phone on its end of the line. Again, this appears to be a problem, but in reality the phone company terminates the connection after a minute of inactivity. This causes the modem to tell UUCP that the connection died, so the problem takes care of itself. The modem is always ready to receive my call well before the time I can dial into the system.

Other considerations

If you decide to use this method heavily, you may fill your /etc/uucp/Systems file with many fake systems that perform pages. Not only does this congest the /etc/uucp/Systems file, but you’ll have so many different codes, you won’t be able to remember what they all mean.

An alternative is to have a single fake system in your /etc/uucp/Systems file. Then, instead of having your script file page to one of many fake systems, you can always page to the same one. Then your script can send you E-mail describing which problem(s) have

occurred. When you log in, you can just read your E-mail to determine the problem. For more information on using mail in a script, see the article "Make a Shell Script Mail You a Summary" in the July issue.

Conclusion

You can use this fairly simple method to have your computer system page you in the event of system emergencies. You can then dial in and avert a disaster. You can easily extend this approach to have your system page you for other events, including the completion of long batch jobs, intruder detection, etc. The rest is up to you!

[The Cobb Group Home Page]

Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.